IRIX Installation Tools & Overlays 2002 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Installation Tools & Overlays 2002 May / SGI IRIX Installation Tools & Overlays 2002 May - Disc 3.iso / relnotes / compiler_eoe / ch1.z / ch1

Wrap

Text File | 2002-04-11 | 48KB | 1,254 lines

- 1 - 7.3.1.3m Base Compiler Execution Environment Release Notes - 2 - 1. _B_a_s_e__C_o_m_p_i_l_e_r__E_x_e_c_u_t_i_o_n__E_n_v_i_r_o_n_m_e_n_t These release notes describe the MIPspro 7.3 release and its maintenance update 7.3.1.3m of Silicon Graphics(TM) IRIX(TM) compiler execution environment (EOE) (compiler_eoe). The IRIX compiler EOE contains compiler execution utilites such as rld and base compiler run-time libraries supplied as DSOs (dynamic shared objects). DSOs are discussed in the dso(5) man page. The IRIX compiler EOE supports MIPSpro compilers in either 64-bit, 32-bit, or high performance 32-bit (n32) compilation modes. For more information about 64-bit and high performance 32-bit interfaces, see the _M_I_P_S_p_r_o _6_4-_b_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e and the _M_I_P_S_p_r_o _N_3_2 _A_B_I _H_a_n_d_b_o_o_k. If you plan to run any IRIX applications, it is important to note that you must install the IRIX compiler EOE. This environment is included in the MIPSpro 7.3 Compiler Execution Environment for IRIX 6.5._x CD (also known as the Compiler EOE CD) and in the IDF CD for IRIX 6.2, 6.3, and 6.4 systems. Packaged with this software is a separate Software License Agreement. This software is provided to you solely under the terms and conditions of the Software License Agreement. Please take a few moments to review this agreement. 1.1 _R_e_l_e_a_s_e__I_d_e_n_t_i_f_i_c_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n Following is the release identification information for the IRIX compiler EOE (compiler_eoe): Software product IRIX compiler EOE Release 7.3.1.3m Product code IDEVFNT-1.2 System software requirements IRIX 6.5 or higher - 3 - 1.2 _O_n_l_i_n_e__R_e_l_e_a_s_e__N_o_t_e_s After you install the online documentation for a product (the relnotes subsystem), you can view the release notes on your screen. If you have a graphics system, select Release Notes from the Help submenu of the Toolchest. This displays the grelnotes(1) graphical browser for the online release notes. For information on options to this command, refer to the grelnotes(1) man page. If you do not have a graphics system, you can use the relnotes command. For information on accessing the online release notes using this command, refer to the relnotes(1) man page. 1.3 _P_r_o_d_u_c_t__S_u_p_p_o_r_t Silicon Graphics provides a comprehensive product support maintenance program for its products. If you are in the United States or Canada and would like support for your Silicon Graphics supported products, contact the Customer Support Center at 1-800-800-4SGI. If you are outside the United States or Canada, contact the Silicon Graphics subsidiary or authorized distributor in your country. 1.4 _I_n_s_t_a_l_l_a_t_i_o_n__I_n_f_o_r_m_a_t_i_o_n If you are installing this option for the first time, to install the subsystems marked default, use the go menu item. To install a different set of subsystems, use the following commands in inst to customize the list of subsystems to be installed: +o install +o remove +o keep - 4 - +o step Then select the go menu item. 1.5 _S_u_b_s_y_s_t_e_m_s The IRIX compiler EOE software (compiler_eoe) for MIPSpro 7.3 includes the following subsystems: compiler_eoe.man.relnotes IRIX compiler execution environment release notes (default) compiler_eoe.man.dso IRIX DSO man page (default) compiler_eoe.man.unix IRIX standard man pages (default) compiler_eoe.sw.cpp Source code preprocessor (default) compiler_eoe.sw.lboot Kernel lboot software (default) compiler_eoe.sw.lib Base compilers execution libraries (default) compiler_eoe.sw.unix IRIX execution environment (compiler) (default) compiler_eoe.sw32.lib Base compilers execution libraries (n32) (IRIX 6.2 only) (default) compiler_eoe.sw32.unix IRIX execution environment ( n32 compiler) (IRIX 6.2 only) (default) compiler_eoe.sw64.lib Base compilers execution libraries (64-bit) (default on R8000(TM) and - 5 - R10000(TM) systems only) compiler_eoe.sw64.unix IRIX execution environment ( 64-bit compiler) (default on R8000 and R10000 systems only) 1.6 _P_a_t_c_h_e_s The following patches are included with the compiler_eoe environment on IRIX 6.2, 6.3, and 6.4: patchSG0003598 Provides updates to the base compiler libraries patchSG0003596 Provides updates to libmp.so to enable OpenMP(TM) support for C and C++ 1.7 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._3_m_ 770106 The file /usr/relnotes/compiler_eoe/chA.z has size 0. This has been fixed. 777196 Gaussian problem with policy module table. A customer running Gaussian98 on IRIX 6.5.x reports a problem with MLD creation. The error returned is: Could not create MLD: Not enough space This has been fixed. 804796 libmp coredumps with OMP_NUM_THREADS == 256. This has been fixed. 822823 F90: acos returns NaN. The program below prints NaN instead of pi for the variable z. This was first observed with the Fortan 90 MIPSpro 7.3.1.2 compiler. This occured when - 6 - the program was compiled -n32 and -64. If variables a and b are declared real*16, then variable z is correct. program test real*8 a,b real*16 x,y,z a = 4. b = 1. x = a * atan(b) y = cos(x) z = acos(y) print *, x, y, z end program test This has been fixed. 821769 Significant performance loss running ADA apps in 6.5.10. This has been fixed. 834590 The .dynamic section of the a.out now has entries for the timestamp and checksum. This allows downstream tools such as SpeedShop to determine if data files match the executable or not. This information has always been in dsos. Warning: a recompiled a.out will now always have different bits. 819091 The linker generates some text on it's own such as the init and fini function driver. Up to now the linker neglected to generate debugging information along with this text making unwinding in the debugger and exception handling routines problematic. This has been fixed. There are still problems with unwinding through linker generated code that has been instrumented for performance evaluation. This will be addressed later. - 7 - 1.8 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._2_m 778798 rld was broken for purify on pthread applications, and the purified pthreaded app could coredump. 783179 rqs/rqs32/rqs64 did not process the multigot dynamic section extensions of multigot executables or DSOs correctly (see man ld, man dso). The error was harmless but could be distressing on a multigot executable (rqs could coredump processing netscape 4.72, for example, but the coredump would NOT harm netscape). If rqs did not core dump on a multigot shared library (DSO) it processed, rqs could corrupt the DSO (if and only if rqs was attempting to 'move' the DSO to a new address and terminated normally: if rqs coredumped then the DSO it was processing is safe). There are very few multigot DSOs: /usr/lib64/libInventor.so.3 is one such. Once damaged, a DSO is not repairable, but must be reinstalled. [If "elfdump -L myfile | grep AUX_DYN" shows a line or more of output then <myfile> is multigot.] 770775 n32, 64 libexc.so The trace_back_stack() and/or exc_unwind() functions could get mixed up and not trace back successfully in programs using pthreads. Now fixed. 770782 n32, 64 libexc.so The exc_unwind() function was not setting sigcontext pc to 0 always. A prudent application will also check for a sigcontext pc < 4 and stop, though the library bug is fixed. 770785 n32, 64 libexc.so The exc_unwind() function was not unwinding past sigtramp(). Fixed. 761433 n32, 64 libexc.so If dbx or WorkShop had set a frame_exit_trap in a routine on the stack, functions such as trace_back_stack() did not work correctly because of the details of the - 8 - implementation of dbx/WorkShop frame exit traps. Fixed libexc.so to deal with this situation so the traceback works. 792734 o32 libexc.so The floating point registers were being picked up incorrectly from memory when libexc unwound the stack. libexc was not reflecting the o32 ABI register save rules during the restoration. Now this works correctly. 673119 rld -ignore_version did not work when -delay_load was used in earlier 7.3 releases. Fixed. 678896 _RLDN32_LIST processing could be wrong if "" was used as the environment variable value to turn off _RLDN32_LIST when _RLD_LIST was set for o32. Fixed. 780001 32-bit Log function returns incorrect results. This has been fixed. 801546 Mips4 version of libfastm gives incorrect results on R5000. 1.9 _B_u_g_f_i_x_e_s__i_n__7_._3_._1_._1_m__(_a_n_d__7_._3_._1_m_) The MIPSpro 7.3 Compiler Execution Environment for IRIX 6.5.x consisted of runtime libraries that contained daddiu instructions that could encounter an arithmetic overflow under certain circumstances. An errata in revision 4 or earlier of MIPS R4000 and R4400 would cause incorrect answers to be produced when encountering arithmetic overflows in executing the daddiu instruction. - 9 - To see what processors are on your system, use the hinv command: Example: % hinv Processor 12: 100 MHZ IP19 CPU: MIPS R4400 Processor Chip Revision: 4.0 FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0 In the example, the Revision 4.0 processor does have the daddiu instruction errata. Although no demonstrable bugs have been found in the base compiler runtime libraries, they also have been recompiled, so as not to use the daddiu instruction in cases where arithmetic overflow can happen. 1.10 _B_u_g_f_i_x_e_s__i_n__7_._3 The following sections describe bugs that have been fixed since the MIPSpro 7.2.1 release. 1.10.1 _B_u_g_s__F_i_x_e_d__i_n__l_i_b_m The following libm bugfixes have been applied from patchSG0003131 into compiler_eoe 7.2.1.1m for IRIX 6.5.1m: 591738, 594226, 595879 Under certain inputs, sin() returns wrong results on systems running on the R5000(TM) CPU. 1.10.2 _B_u_g_s__F_i_x_e_d__i_n__l_i_b_m_p The following libmp bugfixes have been made in compiler_eoe 7.2.1.3m/f for IRIX 6.5.3m/f: 658799 libmp.so is not cpr compliant in IRIX - 10 - versions 6.5.[2,3]. 638713 Various routines invoke mp_numthreads, disabling dynamic threads in IRIX 6.5. 657207 Cannot change number of threads between parallel regions with version 7.3 compilers. The following libmp bugfixes have been made in compiler_eoe 7.2.1.2m/f for IRIX 6.5.2m/f: 554156 Use of the environment variable MP_SLAVE_STACKSIZE leads to unpredictable results. 560707 Fortran MP programs (sproc) with unlimited stack sizes fail. 587240 A performance degradation occurs when OMP_DYNAMIC is set and the program is run under Miser. 599609 libmp MLD information is incorrect on 128 CPUs. 610654 In OpenMP, a barrier within the dynamic extent of a parallel do receives a misleading error message at run time. In particular, a barrier is a synchronization construct, not a worksharing construct. - 11 - 587240 When using the _DSM_MUSTRUN flag and a node has only one CPU and a process gets scheduled to run on that node, libmp attempts to place a process on a non- existent processor. The following libmp bugfixes have been applied from patchSG0003139 into compiler_eoe 7.2.1.1m for IRIX 6.5.1m: 581775 The OpenMP directive, schedule(static,ichunk), ignores ichunk. 581835 The OpenMP directive, ORDERED schedule(dynamic,ichunk), deadlocks if ichunk is not equal to n/nprocs. 590252 Program with the OpenMP ORDERED directive deadlocks under some conditions. 1.10.3 _B_u_g_s__F_i_x_e_d__f_o_r__r_l_d__a_n_d__r_q_s The following rld and rqs bugs have been fixed since the 7.2.1.2m release of compiler_eoe for IRIX 6.5.2m: 608296, 641687, 641192 Various performance improvements have reduced CPU time spent in rld (in small ways). 426852 By default, rld no longer reevaluates name bindings on dlclose(). (The _RLD_ARGS -f argument also uses this new default behavior). This fix makes - 12 - dlclose() fast and eliminates many lazy-text-resolves. It also affects the operation of programs that rely on names being rebound to a different function/data item after a dlclose(). Such programs are erroneous. If the -s option is present with _RLD_ARGS, the old slow method of dlclose is used (this is provided for erroneous programs that depend on the old method). Details are as follows: Each name SHOULD be bound only once by rld, but in complicated circumstances, names can be rebound. If the result of application actions (like dlclose()) is that the rebinding finds a different external definition, the result can be application problems or an application crash (rld does not realize this has happened and will not give a warning). (In addition, having a weak name defined in one DSO and a strong version in a DSO loaded later leads to 'undefined name bindings' and potentially inconsistent application behavior. - 13 - This has always been true but not mentioned earlier. 644389 If an application did an sgidladd() or dlopen(...RTLD_GLOBAL), followed by a dlopen(...RTLD_LOCAL) (and the call to sgidladd/dlopen(...RTLD_GLOBAL) was itself done from a DSO that was opened or added by a dlopen or dladd command), name lookups by rld might not find names made global by the sgidladd() or dlopen(...RTLD_GLOBAL). This was a bug introduced in patch 3378. 638915 If a DSO or executable file had more than 4096 conflict symbols, rqs could core dump. Now the hash table definition allows up to 262,000+ conflict symbols. Although this is the maximum size allowed, if a smaller number will work, a smaller number is used. 649041 If a lazy-text- resolution call involved floating point argument registers and if a call in the -init code in the DSO loaded involved floating point registers, the lazy- text call fp argument registers would be - 14 - destroyed by the -init arguments. Due to details of argument register passing, this bug is seen most readily with the n32/64 ABIs, though it can be reproduced in any of the ABIs. 651001 On delay-loads of DSOs, versions have been ignored for almost all earlier releases of rld. Now rld checks the version number on delay-loads too. The new _RLD_ARGS option -idv turns off DSO version checking for delay-loads in rld and rld.debug, restoring the old, broken behavior. 630359 Debugger stack traces through rld sometimes stops in rld due to mistakes in some hand-written assembly code in rld. Now the stack traces show the callers back to main(), as appropriate. 629117 rld now obeys the general rule that processing is breadth-first (loading of DSOs from liblists and dlsym() name resolution are examples). Details are as follows: In the past, it did almost-breadth-first ordering. Because - 15 - seeing an error in ordering required having duplicate symbol definitions at least 4 levels deep in DSO nested liblists, it is unlikely this bug affected any application. But the ABIs have always been clear and now rld obeys the ABIs. 629128 In the case of a dlclose(), all -fini execution is done for a set of DSOs (where this is the dlclose of the last reference) before any are unmapped. 629707 Nested dlopen/sgidladd/delay- load (that is, invoking dlopen/sgidladd/delay- load from within the -init or -fini code of a dlopen/sgidladd/delay- load) now works even in the pthreads and sproc threads cases. Nested dlopen/sgidladd/delay- load was always problematic (though if no pthreads or sproc threads were in use, it might have appeared to work, as long as none of the nested dlopen/sgidladd/delay- load failed). Use nested dlopen/sgidladd only when absolutely - 16 - required. Use -init only when absolutely required, as the nested dependencies make static prediction of the ordering in which the -init code is to be run difficult. C++ global constructors ordering across compiliation units has always been unspecified by the C++ definition. Adding delay-load to the set of DSOs with mutual constructor calls makes the ordering even less predictable. Using or setting sigprocmask(2) in -init or -fini code is not a good idea because the set of masks seen as ON is affected by rld. The precise behavior of sigprocmask(2) in -init or -fini code depends on which of 1) pthreads, 2) sproc threads, or 3) neither is in use. The details are not specified in these release notes; it is best to avoid setting or resetting the sigprocmask() in -init or -fini code. In addition, it is still difficult to debug -init code in the application startup. 634151 If the filesystem of a DSO had no XFS - 17 - attributes, rqs could fail (refuse to update a DSO to allow quickstart) and fail to print the proper reason message. (The system would operate properly in spite of this rqs error.) Now rqs understands that ENOATTR is not really a failure, allowing the DSO to be quickstarted again, and uses strerror() to properly print all errno values when there is an error. 547873 rld got delay load DSO visibility slightly wrong in MIPSpro 7.2.1. Too restrictive in symbol visibility. 648641 ssrun(1) could interact with rld, causing some -init functions to not run correctly. This fix corrects the rld part. Note: it is erroneous for a signal handler to call dlopen(), dlclose(), sgidladd(), sgidlopen_version(), dlsym(), or dlerror(). Similarly, no function call in a signal handler is allowed to cause a delay-load of a DSO (this is an implicit dlopen and it is not correct). In fact, very few functions - 18 - are legally callable from a signal handler. the dl* functions are not so callable. It is up to applications to ensure that such does not happen. The following bugs have been fixed since the 7.2.1.1m release of compiler_eoe for IRIX 6.5.1m: 549912 In rld there were potential deadlock and signal-mask handling problems. 554703 rld needs to emit a better message in case of bad DSO/executable file. 558948 In rld, there was an incorrrect implementation of add_version_to_name(). 568510 rqsall, under certain circumstances, falls into an infinite loop. 586353 A call occurs to a function defined by rld at 0xffffffff. 589044 An rld warning does not give the object name. 600777 rld incorrectly performs an alloca() in a loop. - 19 - 604402 An rqsall manpage example does not work. 608753 The rld RHF_NO_LIBRARY_REPLACEMENT argument is not honored. 614133, 615089 rld is too large and could be smaller with its own vsnprintf. 615441 rld does extra useless lookups, degrading performance. 620471 An application that performs a dlopen experiences slow performance due to poor string compare code.